Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Microsoft Online Certificate Status Protocol (OCSP)

Validating OCSP integration

search

Validating OCSP integration

To validate that OCSP is operating properly after integration with a ProtectServer 3 HSM, complete the steps described below.

Generate a certificate request

You must first generate a certificate request.

To generate a certificate request

  1. Log on to the OCSPCL machine and generate a certificate request.

    Thales recommends using the template structure shown below (Try to use different vendors’ cryptographic service providers).

    [Version]
Signature = "$Windows NT$"
[NewRequest]
Subject = "C=IN,CN=OCSPCL"
HashAlgorithm = SHA256
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "<Provider_to_be_used>"
KeyUsage = 0xf0
MachineKeySet = True
RequestType = PKCS10
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1
[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty

  2. Save the above template as test.inf file. Ensure that the Provider Name variable is provided with the quotation marks around it.

  3. Open the command prompt window and execute the following command:

    certreq –new test.inf test.req

    A certificate request called test.req will be generated.

  4. Execute the following command in command prompt:

    certreq –submit –attrib “CertificateTemplate:WebServer” test.req

    A window displays confirming which CA to use. Select the OCSPCA entry and select OK.

  5. A dialog displays to save the certificate to a file.

  6. Save the certificate file and select OK. After a short pause, a message “Certificate Successfully Generated” displays on the command prompt and a certificate file is generated.

Test the certificate’s origin

After generating a certificate request, test the certificate's origin.

To test the certificate’s origin

  1. Log on to OCSPCA and go to the Certification Authority tool by navigating to Start > Administrative Tools > Certification Authority.

  2. In the Certification Authority snap-in, publish a new CRL by clicking Certification Authority (Computer)/CA name/Revoked Certificates in the console tree. Then, right-click on the Revoked Certificates folder, point to All Tasks, and select Publish.

  3. Select New CRL and select OK.

  4. Open the Certification Authority snap-in and right-click on the CA. Select Properties.

  5. On the Extensions tab, verify that the extension is set to CRL Distribution Point (CDP) in the drop-down menu. Select any listed CRL distribution points, select Remove, and select OK.

  6. Select Apply. A dialog displays stating that you need to restart the service.

  7. Select OK and wait for the service restart.

  8. Verify that clients can still obtain revocation data. Execute the following on OCSPCL:

    certutil -url test.cer

  9. The URL Retrieval Tool dialog displays. Select the CRLs (From CDP) radio button and select Retrieve.

  10. Select the OCSP (From AIA) radio button and select Retrieve. The list should contain an OCSP entry showing the web address of the OCSP server. If it is working correctly, the word Verified displays in the first column in the list.

  11. Select the Certs (from AIA) radio button and select Retrieve. One or two entries should be listed, with Verified next to them.

    Note

    If Certificate Authority Web Enrollment is not installed on the CA, an entry with AIA may display as Failed. However, as long as one of the entries in the Certs (from AIA) section reads Verified there should be no problems with the set-up.

Verify the OCSP integration

After completing the steps above, verify the OCSP integration.

To verify the OCSP integration

  1. Open a command prompt and execute:

    certutil –verify test.cer > test.txt

  2. When the above command has been completed, open the test.txt file. The file should contain the information like this:

    Issuer:
    CN=ptktest-AA3837-CA
    DC=ptktest
    DC=com
Name Hash(sha1): 7722c50539535b3b75098d266fcc906095d56997
Name Hash(md5): 11cfe24d80af1bd482375a110d1622e3
Subject:
    CN=OCSPCL
    C=IN
Name Hash(sha1): cfd846a61136a61f14f4c257c6b095679ec95b83
Name Hash(md5): c8af047e4fc8969dfe6e38283666b539
Cert Serial Number: 4d000000049814874a38c226f1000000000004

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 13 Minutes, 38 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 13 Minutes, 38 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=ptktest-AA3837-CA, DC=ptktest, DC=com
NotBefore: 12/9/2021 10:03 AM
NotAfter: 12/9/2023 10:03 AM
Subject: CN=OCSPCL, C=IN
Serial: 4d000000049814874a38c226f1000000000004
Template: WebServer
Cert: 13258971d8bfcce3534a121b031be348b596f71c
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    CRL 02:
    Issuer: CN=ptktest-AA3837-CA, DC=ptktest, DC=com
    ThisUpdate: 12/9/2021 10:05 AM
    NextUpdate: 12/16/2021 10:25 PM
    CRL: ec70fdb1849dab41aac000f9b108497f5e9c7e70
    Delta CRL 02:
    Issuer: CN=ptktest-AA3837-CA, DC=ptktest, DC=com
    ThisUpdate: 12/9/2021 10:05 AM
    NextUpdate: 12/10/2021 10:25 PM
    CRL: 38aac55697b0d0767c41817d419f6132dc1af012
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=ptktest-AA3837-CA, DC=ptktest, DC=com
NotBefore: 12/9/2021 12:11 AM
NotAfter: 12/9/2026 12:21 AM
Subject: CN=ptktest-AA3837-CA, DC=ptktest, DC=com
Serial: 44d75012c99ba39a451099d2012b2423
Template: CA
Cert: 165b33a34e744102a4dfa6f193f5a46fc4663cb1
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

Exclude leaf cert:
Chain: 092c18398936cbf0a002a32cfb0f2d76b12e3957
Full chain:
Chain: caf11509b76eeeb9fb623423c48993239208d68c
------------------------------------
Verified Issuance Policies: None
Verified Application Policies:
    1.3.6.1.5.5.7.3.1 Server Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

  3. Ensure that the above output includes the following:

    Verified Issuance Policies: None
Verified Application Policies:
    1.3.6.1.5.5.7.3.1 Server Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

These commands demonstrate that the OCSP server is operating correctly without any errors. The most important component of the above example is the Leaf certificate revocation check passed line as this demonstrates that the OCSP service is returning the certificate status as Good.

If the log generated by the verify command does not include the above section (or similar) and has errors in the output, we recommend you restart the OCSP server and client machine, and run the verify command again on the certificate file.

On this page